Developer Relations

Are you qualified for developer relations?#

You are reading a course written by a developer relations professional. If you follow 75% of the advice here, you will be well qualified to be a developer relations professional. It just so happens that much of the same advice helps coders in the non-coding aspects of their careers (which is the only reason this course made sense to write).

So, if you’ve read the course and practiced these principles, strategies, and tactics, we can assume you’re qualified and should easily get the job. Our task now is to figure out whether you want the job.

Titles for this job#

There are many names for this job:

• Developer Evangelist
• Developer Relations
• Developer
• Developer Advocate
• Developer Experience Engineer

For convenience, we’ll just say “DevRel,” which is slightly better but not as fun as “Developer Avocado.”

As you might expect, titles aren’t standardized. In theory, they are different roles, but the reality is everyone performs some ill-defined mix of all these roles. The best you might observe in titling trends is that “Evangelist” is on its way out (too much “I’m telling you to use my product”), and “Advocate” and “Developer Experience” are on the way up (more focus on being the user’s champion internally, or making the conversation a “two-way street”). However, the shift in titles may not track closely with the actual behaviors and incentives set up by the company.

It’s not a common job#

It’s not a common job by any means; it only makes sense for developer-focused companies to hire DevRels. Even in a “dev tools” company, there might be a hundred developers to 1 DevRel, but it is a very visible job (this is a very good thing for mid-career developers). This means that even as a developer, you’ll see a lot of DevRel folks doing talks and such, and you might naturally become curious about joining their ranks.

Where do developer relations belong?#

This question cuts to the heart of DevRel: Does DevRel belong in product or marketing or on its own? Cynics will say marketing, users will hope it’s the product, and DevRel folks want DevRel to stand alone as its own department. It actually depends on how the company is run and how much they walk their own talk. If you call someone a “Developer Advocate,” but they spend functionally all their time producing content, and are evaluated based on user growth, and have no input on product prioritization, how much are they really “advocating” for users instead of to users?

DevRel programs are expensive, and the best way we know how to justify ROI on these things are all Marketing metrics - which turns DevRel into Marketing despite the best intentions of everyone concerned.

What gets measured gets managed, and DevRel is only just beginning to have an open conversation about how best to measure DevRel (there may be no answer). Better run DevRel programs will be carefully designed to prevent this, but enough DevRels are just “very expensive affiliates” or rebranded “developer-friendly marketing,” that it is worth a quick warning to you.

As a potential DevRel, this is something you need to investigate as you consider various companies and also figure out where your own preferences lie.

Learning in public#

There can be too much of a good thing. You have been told that writing, speaking, and learning in public are good for you, but it is a VERY different proposition to have it become a full-time job. Some people will love being paid to raise your profile alongside the company’s and to enhance these very critical skills for audience and network-building. For others, taking what you used to do for fun and turning it into a job, with attendant metrics, quotas, and a weekly schedule, kills all the fun and makes you a slave to the “content grind.”

There is also the matter of perceptions: first, that you are now a paid shill, and second, that you are no longer a “real developer.” Both are a little bit correct, which is the worst kind of perception to fight. The truth is shades of gray.

Genuine enthusiasm#

To be an effective DevRel, you must advocate from a place of genuine enthusiasm. However, it is true that you are paid to plug your company’s product, and while most employers are fine with you also talking about other issues important to developers, all of them will constantly pressure you to increasingly plug your company. You have to balance this pressure against your own interests and industry credibility.

Address problems real developers face#

To be a relatable DevRel, you must be able to demonstrate that you can still address problems real developers face. However, it is true that you no longer maintain a product in production, and you do spend a lot of your time making tutorials that look nice in a talk or blogpost but omit a lot of the inconvenient realities like testing, maintenance, and cost (since you, of course, don’t pay for your own company’s products).

You will have to work hard to both demonstrate your product’s production-ready-ness (some products don’t have this problem) and also make it approachable to newcomers (all products have this problem). You should avoid being too clubby with other DevRel people on the “conference circuit” to the exclusion of “real developers,” most of whom only attend one conference a year.

Online communities#

Travel used to be a major part of the job and usually starts as a perk (Wow, I visited forty countries this year!) and becomes a chore. In the post-coronavirus world, the focus has entirely pivoted to online communities, which is great for the environment, but also DevRel marketing budgets.

It’s not easy#

Nobody said it was easy. Couple this with the long-term reality of DevRel, and it might be a dead end. It may be hard to switch from DevRel back to engineering or engineering management (although, perhaps, no harder than other switches; it’s difficult to say). Additionally, there is no room in the C-suite for DevRel folks currently, while other tracks have clear paths to CTO or CPO.

The job is rewarding#

Patrick McKenzie observation#

As for the “dead-end career” fear, Patrick McKenzie has this to say:

🔍 “An observation: Every developer evangelist I know goes into a much better job right after they quit being an evangelist. This is not true of other engineering jobs with checkered reputations, like, The Build Guy for example.”

Why do developer evangelists get upgrades but The Build Guy(s) do not? My bet is because evangelists literally spent years meeting thousands of people and showing them, “Hey, I’m going to live code in front of you while also making my employer’s fat stacks of money. You run a company and could use both engineers and money. You should probably remember my name, you know, just in case.”

I, unfortunately, have not done this job long enough to have enough data to prove or disprove this. It’s quite possible nobody has. It is pretty common to see DevRels go on to other DevRel jobs, though that is neither here nor there. It does feel like DevRel can be close kin to product management for a technical product because of a similar focus on users.

The ultimate skill of a DevRel#

DevRels don’t have a monopoly on speaking or writing about the company. The less jealously they guard this with, the better. In fact, the most successful DevRel programs are great partners for internal engineering teams to speak out with pride in their work and their products. This basically always works out well— the engineering teams get to brag, audiences see nontrivial work from unquestionably “real” engineers, and customers get to peek behind the curtain of what they’re buying.

It even makes hiring easier. Dan Luu has great thoughts on how good corporate engineering blogs are written. At companies with very engaged user bases, user groups and community meetups can perform this function too. Pragmatically speaking, enabling the voices of others to be heard is the only way to scale DevRel’s reach beyond a linear growth in DevRel headcount. Being able to build community is, therefore, the ultimate skill of a DevRel.

Recommended readings#

I recommend reading: